Communications systems evolve more and more towards an Internet Protocol (IP)-based network. They typically consist of many interconnected networks, in which speech and data is transmitted from one terminal to another terminal in pieces, so-called packets. IP packets are routed to the destination by routers in a connection-less manner. Therefore, packets comprise IP header and payload information, whereby the header comprises among other things source and destination IP address.
For scalability reasons, an IP network uses a hierarchical addressing scheme. Hence, an IP address does not only identify the corresponding terminal, but additionally contains location information about this terminal. With additional information provided by routing protocols, routers in the network are able to identify the next router towards a specific destination.
When a terminal powers on, it configures an IP address that is based on the IP address prefix of the access network. If a terminal is mobile, a so-called mobile node (MN), and moves between subnets with different IP prefix addresses, it must change its IP address to a topological correct address due to the hierarchical addressing scheme. However, since connections on higher-layers such as TCP connections are defined with the IP addresses (and ports) of the communicating nodes, the connection to the active IP sessions breaks if one of the nodes changes its IP address, e.g. due to movement.
Mobile IPv6 (MIPv6)
Mobile IPv6—also denoted MIPv6— (see D. Johnson, C. Perkins, J. Arkko, “Mobility Support in IPv6”, IETF RFC 3775, June 2004, available at http://www.ietf.org and incorporated herein by reference) is an IP-based mobility protocol that enables mobile nodes to move between subnets in a manner transparent for higher layers and applications, i.e. without breaking higher-layer connections. That is, the mobile nodes remain reachable while moving around in the IPv6 internet network. The main principle of MIPv6 is that a mobile node is always identified by its Home Address (HoA), regardless of its topological location in the internet, while a Care-of Address (CoA) of the mobile node provides information about the current topological location of the mobile node.
In more detail, a mobile node has two IP addresses configured: a Care-of Address and a Home Address. The mobile node's higher layers use the Home Address for communication with the communication partner (destination terminal), from now on called Correspondent Node (CN). This address does not change and serves the purpose of identification of the mobile node. Topologically, it belongs to the Home Network (HN) of the mobile node. In contrast, the Care-of Address changes on every movement resulting in a subnet change and is used as the locator for the routing infrastructure. Topologically, it belongs to the network the mobile node is currently visiting. One out of a set of Home Agents (HA) located on the home link maintains a mapping of the mobile node's Care-of Address to mobile node's Home Address and redirects incoming traffic for the mobile node to its current location. Reasons for deploying a set of home agents instead of a single home agent may be redundancy and load balancing.
Mobile IPv6 currently defines two modes of operation: bi-directional tunneling (FIG. 1) and route optimization (FIG. 2). Using bi-directional tunneling, data packets sent by the correspondent node 101 and addressed to the home address of the mobile node 102 are intercepted by the home agent 111 in the home network 110 and tunneled to the Care-of Address of the mobile node 102, which is anchored at the foreign network 120. Data packets sent by the mobile node 102 are reverse tunneled to the home agent 111, which decapsulates the packets and sends them to the correspondent node 101. Reverse tunneling means that packets are transmitted by the mobile node via an additional reverse tunnel (to complement the “normal” one) that starts at the mobile node and terminates at the home agent.
For this operation in MIPv6, only the Home Agent 111 is informed about the Care-of Address of the mobile node 102. Therefore, the mobile node sends Binding Update (BU) messages to the Home Agent. These messages are sent over an IPsec security association, and thus are authenticated and integrity protected. In order for the MN to have IPsec association with the HA, the MN needs to perform bootstrapping a-priori. Bootstrapping is the process of obtaining at least the following information: a home address, a home agent address, and a security association with home agent. This information is needed before the MN registers a CoA with the home agent. The process may last several seconds because several round-trip-times between MN and HA are needed.
A drawback is that if the mobile node is far away from the home network and the correspondent node is close to the mobile node, the communication path is unnecessarily long, resulting in inefficient routing and high packet delays.
The route optimization mode (see FIG. 2) can prevent the inefficiency of the bi-directional tunneling mode by utilizing the direct path between correspondent node and mobile node. When using route optimization, the mobile node sends binding update messages to the correspondent node, which then is able to directly send data packets to the mobile node (a type 2 routing header is used to send the packets destined to the mobile node's home address on the direct path to the mobile node's care-of address). Of course, the correspondent node has to implement Mobile IPv6 route optimization support.
More specifically, in order to perform route optimization, the mobile nodes and correspondent nodes exchange signaling messages, being part of the Mobility Header protocol, which is an extension header used by mobile nodes, correspondent nodes and home agents in all messaging related to the creation and management of bindings. With respect to route optimization, 4 message types are specified in the mobility header protocol.
FIG. 3 depicts the signaling flow performed for RO in MIPv6. The protection of Binding Updates sent to correspondent nodes does not require the configuration of security associations or the existence of an authentication infrastructure between the mobile nodes and correspondent nodes. Instead, a method called the Return Routability (RR) Procedure is used to assure that the right mobile node is sending the message.
The Return Routability Procedure enables the correspondent node to obtain some reasonable assurance that the mobile node is in fact addressable at its claimed Care-of Address as well as at its home address. Only with this assurance is the correspondent node able to accept Binding Updates from the mobile node which would then instruct the correspondent node to direct that mobile node's data traffic to its claimed Care-of Address.
This is done by testing whether packets addressed to the two claimed addresses are routed to the mobile node. The mobile node can pass the test only if it is able to supply proof that it received certain data (the “keygen tokens”) which the correspondent node sends to those addresses. These data are combined by the mobile node into a binding management key. The integrity and authenticity of the Binding Updates messages to correspondent nodes is protected by using the binding management key.
The MN sends two messages to the CN, each however over a different route. One message—Home Test Init (HoTi) message—is sent to the HA over the MIP IP-in-IP tunnel (not depicted in FIG. 3), which in turn forwards the message to the CN. A mobile node sends a Home Test Init message to the correspondent node (via the home agent) to acquire the home keygen token. As apparent from FIG. 3 the message comprises the home init cookie that the CN must return later, and conveys the home address of the MN to the CN. The other message—Care-of Test Init (CoTi)—is sent directly to the CN in order to obtain the care-of keygen token. The CoTi message informs the CN about the current Care-of Address of the MN, and comprises the care-of-init cookie. If the CN also uses MIPv6, the HoTi and CoTi messages are transmitted via the HA of the CN to the CN.
After receiving the HoTi and CoTi messages, the CN sends two messages back to the MN again over different routes. The Home Test (HoT) message is sent to the MN's HoA, i.e. to the HA, in response to the HoTi message. The HA then forwards the message to the MN over the MIPv6 tunnel. Accordingly, the Care-of Test (CoT) message is sent directly to the MN. Both messages HoT and CoT respectively contain “home keygen token” and “care-of keygen token”, respectively along with the home init cookie and the care-of-init cookie received from the previous HoTi and CoTi messages. Both tokens are based on CN's currently active secret key, nonces, and home or care-of address (respectively).
After the HoT and CoT messages arrive at the MN, the MN uses the keygen tokens and generates a binding management key from the tokens received with the HoT and CoT messages. After the mobile node has created the binding management key, it can supply a verifiable Binding Update to the correspondent node. After receiving the Binding Update message, the CN can update its binding cache with the binding of MN's HoA and CoA. The Binding Update message is acknowledged with a Binding Acknowledge message. The exchange of HoTi-HoT and CoTi-CoT messages is used by the CN to verify the HoA-CoA mapping without pre-arranged security association.
Thus, MIPv6 allows to optimize the route between the CN and the MN by allowing a mapping in the CN of the HoA and CoA of the MN, so that the CN can communicate directly with the MN.
Proxy MIPv6 (PMIPv6)
Mobile IP is categorized as host-based (or client-based) mobility management, since the mobility-related signalling is between the host (or client) and the HA. Hence, it is sometimes called Client Mobile IP (CMIP). Another approach, targeting the IP mobility management in limited geographical regions, is managed by the network and therefore is transparent to the MN. This approach is referred as network-based, localized IP mobility.
One main characteristic of network-based mobility is that the access network entities are appropriately configured to detect the MN movement and to exchange information about the current location of the MN, so that the MN does not need to be involved in the mobility process. Therefore, the mobility-related signaling over the wireless interface is avoided. Other advantages of the network-based mobility management are less packet overhead over the air, since no MIPv6 encapsulation is needed, and mobility support for simple IP nodes (i.e., non-MIP-capable nodes). The Internet Engineering Task Force (IETF) organisation is working on such an approach for localized mobility management based on the Mobile IP protocol. Since a network entity is acting as a proxy on behalf of the MN, the protocol is called Proxy Mobile IP (PMIP). There is a variant for IPv6 called PMIPv6 and a variant for IPv4 called PMIPv4. Most of the embodiments of this invention assume PMIPv6 as protocol for network-based mobility management, but the invention is not limited to PMIPv6. It may also be applicable to other network-based mobility management protocols such as PMIPv4.
To provide mobility support to any IPv6 host within a restricted and topologically localized portion of the network and without requiring the participation of the host, proxy mobile IP (PMIP) introduces a new logical entity called Mobile Access Gateway (MAG) which is the proxy mobility agent in the network which manages the mobility related signaling for a mobile node that is attached to its access link. It is the entity responsible for tracking the mobile node's attachment to the link and for signaling the mobile node's local mobility anchor. The MAG is usually co-located with the access router (AR) and performs Mobile IPv6 signaling message on behalf of mobile node, e.g. can send BU messages on behalf of a MN. These BU messages are marked with a flag, so that they can be identified as Proxy BU (PBU) messages. Furthermore, PBU messages may contain a Network Access Identifier (NAI) option, a home prefix option, and a timestamp option. The NAI option contains the NAI, which has the form of “username@realm” and which is used to identify a MN. The home prefix option contains the HoA or home prefix of the MN. In the so-called per-MN-prefix addressing model, every MN has a unique home prefix and the MN's global IP address(es) is configured based on this prefix. The unique home prefix can be used in the PBU messages instead of a HoA. The timestamp option contains the time the PBU has been sent by the MAG and is used by the HA to identify the freshness of the PBU messages. The sequence number value of the PBU message is ignored by the HA.
A Local Mobility Anchor (LMA) is the home agent for the mobile node in the Proxy Mobile IPv6 domain. It is the topological anchor point for the mobile node's home prefix and is the entity that manages the mobile node's reachability state. It is important to understand that the LMA has the functional capabilities of a home agent as defined in Mobile IPv6 base specification and with the additional required capabilities for supporting Proxy Mobile IPv6.
When a MN attaches to a new MAG, it authenticates with the network using the EAP framework and an EAP method such as EAP-AKA. The MAG typically acts as pass-through authenticator and forwards the EAP packets to the AAA server/infrastructure related to the MN. The MN uses a NAI as identifier. If the network authentication is successful, the MAG obtains the MN's profile from the AAA server including the MN's home prefix. The MAG then sends a PBU to the HA and announces the home prefix to the MN. After the MN authenticates with the AR, it starts the IP configuration, i.e. it configures a link-local (LL) IP address, performs Duplicate Address Detection (DAD) for the LL address by sending a Neighbour Solicitation (NS) message to the solicited-node multicast address of the LL address to be checked. If the procedure is successful, the MN sends Router Solicitation (RS) message to all-routers via a corresponding multicast address and waits for receiving a Router Advertisement (RA). The AR/MAG responds with unicast RA including the MN's home prefix.
After configuring a global IP address, the MN is IP reachable and can use the IP address as long as it moves within the PMIP domain. An exemplary signalling flow for PMIPv6 during initial attachment procedure, as described above, is shown in FIG. 4.
FIG. 5 depicts one exemplary scenario, in which two mobile nodes, MN1 and MN2, are located in visited networks (VN) and want to start a communication session between each other. MIPv6 tunnels exist between the mobile nodes MN1/MN2 and their corresponding home agents, HA1/HA2 in the home networks HN1 and HN2. For illustration purposes, the MIPv6 tunnels between MN1 and HA1 and between MN2 and HA2 are omitted from FIG. 5.
In both VNs a PMIPv6 service is offered to the MNs, i.e. the MN1 keeps the same Care-of-Address (CoA) while it moves within the VN1. MN1 is connected to MAG1 and registered at LMA in VN1. Correspondingly, MN2 is connected to MAG2 and registered at LMA2 in VN2. Again, the PMIPv6 tunnels between the MAG1 and LMA1 and between MAG2 and LMA2 are not illustrated in FIG. 5 so as to enhance its overview.
Since the data path between MN1 and MN2 traverses the home networks (solid line in FIG. 5), the end-to-end delay of the data packets is significant. If MN1 performs MIPv6 route optimization, the resulting data path would be the dotted line traversing from LMA1 (in VN1) to HA2 (HN2) and further to LMA2/MAG2 in VN2, since data packets from MN2 are directly transmitted to the MN1's CoA, which is anchored at LMA1. A further optimization would be, if the MN2 also performs MIPv6-RO, which would result in the data path denoted by the dashed line going directly between LMA1 (in VN1) and LMA2 (in VN2), without traversing any of the HNs, HN1 and HN2.
The described scenario can be mapped to the System Architecture Evolution (SAE) work item standardized in 3rd Generation Partnership Project (3GPP). Using SAE terms, the interfaces MN1-HA1 and MN2-HA2 can be described as S2c interfaces.
Another example scenario is depicted in FIG. 6. In this scenario there are no changes regarding MN1. MIPv6 is used to connect MN1 to HA1 in HN1, and PMIPv6 is offered to MN1 in the visited network VN1. However, unlike FIG. 5, MN2 is connected via PMIPv6 from the visited network VN2 to the home network HN2; no MIPv6 is used for MN2. A PMIP tunnel is setup between the MAG2 in VN2 and LMA2 in HN2, which is however omitted for illustration purposes.
Having such a scenario, the PMIPv6 service is offered to the MN2 in both HN2 and VN2, which means that the MN2 keeps the same IP address while moving between HN2 and VN2. The data path without any RO is denoted by solid line. The dashed line shows the data path if MN1 would perform MIPv6 RO. MN2 cannot of course perform an MIPv6 route optimization.
As apparent from FIGS. 5 and 6, the data path between the mobile nodes, MN1 and MN2, is not optimal, even after respective MIPv6 ROs are performed by both MNs. Similar problems are also present in other scenarios, such as when MN2 is stationary, i.e. MN2 has no mobility management service.